home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Turnbull China Bikeride
/
Turnbull China Bikeride - Disc 2.iso
/
STUTTGART
/
GRAPHICS
/
TOOLS
/
SPRVIEW
/
!SprView
/
history
< prev
next >
Wrap
Text File
|
1993-08-17
|
12KB
|
291 lines
// --------------------------------------------------------------------------
// !SPRITEVIEW HISTORY
!SpriteView is an application I wrote as an introduction to programming in
the Wimp environment using C++: the (very) partial GNU C++ implementation
written by Thomas Aeby (ported down on 27-Apr-93). I've had to write my own
library of functions but I wouldn't wish *them* on anybody!
Any additions/alterations that have come about due to other people's
comments/suggestions have those people's names in brackets next to them. For
example, I started this history file on 28-Jul-93 (Joss Smith).
// --------------------------------------------------------------------------
// VERSION: 0.08a 28-Jul-93
So far, I've written a lot of code. The application is set up to allow only
one window but is written to provide for more.
All info in the program information window is filled in once the application
starts.
The windows in which the sprite reside are customized when the sprite is
loaded.
Memory for sprites is taken from the RMA since I thought the Wimp might need
to be able to find the data for redraw whether the application is paged in or
not. That may not be the case though...
I split up the code last night.
SpriteView:
• can load a sprite into a (correctly sized) window.
The window has no system area (even no border). To make redrawing
faster, the icon and the window have transparent background colours.
• allows the user to drag the window around the screen
This entails dragging the sprite with select
• allows the user to resize the window
This entails dragging the sprite with adjust
• is riddled with error checking
I have made the decision that good error reporting is vital. I'm quite
happy with the set up although it makes the code a lot more cumbersome.
There are even mechanisms for reporting non-fatal errors and (in fact)
if a Sprite is not loaded, the application can continue without any
problems.
Problems:
• drag operations
As yet they are incomplete; more control is needed over the window and
which part of the sprite is showing. So far, dragging the window means
it is brought to the front (and there is no back icon) and resizing it
leaves it where it is on the window stack. This is caused by the use
of select and adjust.
• minimum window size
The window can be made VERY small and this is not really desirable.
However, I have to allow sprites of any size so I must make the
minimum size different for different size sprites, with an upper bound
for the minimum size.
// VERSION: 0.09a 28-Jul-93
The drag operations now work as desired. That is we now have:
• move sprite
linked to Drag
• resize sprite
linked to Alt-Drag
• scroll sprite (horizontal, vertical, and bi-directional)
linked to Shift-Drag
Adjust and left,right Shift Keys dictate the behaviour of the scroll
I've also implemented
• put to back
linked to DoubleClick
I've created a !help file which details all of the behaviour I would like in
the finished product so far.
// VERSION: 0.10a 29-Jul-93
Fixed bugs, now:
1) windows open on top.
2) minimum allowed area depends on sprite
3) sprites with masks have filled backgrounds
Have decided on a policy for having multiple frames on the same sprite. I've
implemented the ideas though have not yet had the courage to allow more than
one window in my compiled code.
Got a preliminary sprite menu up and running. The menu contains:
• New View
Not yet implemented.
• Lock/Unlock
Allows you to fix the position of the window and disables all drag
events. It also ignores any OpenWindow block for locked windows
and substitutes the status of the window when lock was selected
but I don't think OpenWindow gets generated so the window drifts
up and down in the stack. I've allowed DoubleClick to remain.
• Remove
Works for one Sprite and should work for more.
// VERSION: 0.11a 30-Jul-93
I have now written the scroll drag operations myself rather than relying on
the Wimp so that the drag looks like the sprite is being moved by the pointer
rather than against it. This has a more intuitive feel.
Implemented New View and tested !SpriteView with a maximum of 5 sprite
windows allowed. It worked fine! One problem, though, is that the menu
disappears even if you hold adjust down. It shouldn't but I have a feeling
the sequence of operations I perform in NewView induces this.
The new window opens at the bottom left of the screen.
Have had one unexplainable crash which happened whilst using a different
application. I don't think I can recreate it but have decided it might be
linked to my use of RMA space directly for my sprites.
// VERSION: 0.12a 31-Jul-93
I have written all the allocation and deallocation code for my SpriteWindows
myself and no longer use RMA blocks or mallocs. I was just going to use
mallocs but found that no memory was released from the wimpslot once it was
claimed even if I knew my code had freed the pointers.
The memory management is now written to use a RISC OS2 style Heap structure
with memory being returned automatically when enough free space presents
itself at the end of the heap. Shifting is not yet performed though adjacent
free blocks are merged.
I've included diagnostics which are outputted while the application is
running, into a file called 'DIAGNOSTICS' in the SpriteView directory (if I
set up the code to do so of course).
// VERSION: 0.13a 31-Jul-93
At last I've got my sprite shifting (Shift-Drag = Scroll Window) to work
properly. The initial direction of the drag dictates which way the window can
move. If Adjust is used to start the drag, the window can be shifted in any
direction.
I've taken resizing from the wimp now. You can resize any side/corner and the
picture remains still unless the frame size expands so as to make moving
necessary. Basically, it does the same as the Adjust Size icon but you can
resize in many different ways. Once again, the mouse movement defines the
side (corner if Adjust is used).
I've also added a different way of shifting the sprite: the sprite remains
fixed and the window travels over it. I have put checks in to make sure the
window doesn't disappear off the screen but the upper edge check is not quite
right yet.
Realized that you can at present resize the window so that it disappears off
the screen but fixed it.
Made the pointer disappear while the drags were taking place.
// VERSION: 0.14a 2-Aug-93
I've increased the number of windows allowed to 30.
There were a few bugs in the error trapping concerned with memory allocation
and sprite file loading and so I've got rid of these. I've had to rewrite the
file size check since I wrote it using a standard library function and so the
application crashed when the operation failed.
// VERSION: 0.15a 2-Aug-93
Implemented the stick function (which involved smartening up the poll loop a
little). This is a nice feature (IMO) so I'll dedicate this version to it!
// =========================================================================
// RELEASE 1
// =========================================================================
// VERSION: 0.16 4-Aug-93
Reimplemented file loading so that only the first sprite in the file was read
in rather than the whole file (Ian Fry). I've also moved towards allowing
other sprites in files to be loaded without ever having to read in the whole
file.
Dropped the 'a' from the version number. They are all alphas so far.
Read PageSize instead of assuming it was 32K (Ian Fry).
Updated the !Help file to make it acceptable for a release.
// VERSION: 0.17 5-Aug-93
Added Save box. Doesn't work yet. It also gets picked up as an
Information Window every now and again and gets its Ok box altered.
Added File Information Window. Just Ctrl-Drag file onto icon or press Ctrl
while double-clicking on the icon. I've got this window working fairly well
now. It brings up a list of all the sprites in the given file and allows you
to load a sprite in by clicking with Select on the button next to its name.
You can remove the sprite by pressing Adjust on the button or using the
sprite's menu. The only real bug is that error with the Save Box.
(Note: The information is read from the file so no actual sprite
images are held in memory unless displayed).
I've rejected idea of putting all data on the sprite list. I'll provide some
means of getting a little Sprite Info window that tells you more about a
particular sprite but I don't want to clutter the screen with a massive
table.
Speeded up loading from big files by storing offsets (of sprites into sprite
files) in memory.
Found bug in Save box/Info Windows.
// VERSION: 0.18 6-Aug-93
Fixed the bug with Save box/Info windows.
Got the Save box completed. The Save box is a little non-standard since the
leafname is kept seperate from the pathname. I've made it so that the OK
button goes in when the save gets close to working or does actually work
(i.e. an error message should be displayed if the button goes in and the save
fails).
// VERSION: 0.19 8-Aug-93
Added ability to save from other applications. Decided that allowing Ctrl-Drag
functionality was not really required so only one sprite is loaded and displayed.
Started an 'Edit' submenu to allow a few changes to sprites to be made.
So far I have implemented 'Crop' which creates a completely fresh sprite
of the presently viewed section of the current sprite.
// VERSION: 0.20 16-Aug-93
Added 'Flip X' and 'Flip Y' to the Edit menu and made sure that 'New View's
onto the same sprite were updated instantly.
Fixed the readjustments so that resize can allow sprites to be resized
bigger than the screen as long as the picture is still visible.
Implemented key shortcuts. So far:
^O - open window fully
^N - new view
^R - remove sprite window
Added a submenu to the Remove option on the Sprite Window menu. Now have the
ability to remove the sprite or all copies of that sprite or all sprites
in the application.
// =========================================================================
// RELEASE 2
// =========================================================================
// VERSION: 0.21 17-Aug-93
Fixed bug in key shortcut code by making it necessary to click in the window
for it to gain the input focus. Added the following key shortcuts:
^B - put to back
^C - Crop sprite
^F - bring to front
left arrow - flip x
right arrow
up arrow - flip y
down arrow
Spotted problem with key shortcuts in that a window can be removed while its menu
is still open.
Added ability to grab the contents of a window or an area of the screen though
I'm not yet sure it *always* works yet since I may not be accounting for
wastage properly when claiming enough memory and hence there may still be some
'Not enough memory to create sprite' errors.
// FUTURE PLANS
Must rid myself of the ^R bug (closing a window when its menu is open)..
I might implement an info box for saying which mode it was defined in and
its size, for example.
May provide multitasking error reporting.
May (eventually) cater for sprites with masks properly. Hmmm.
Would like to allow other editing facilities on sprites: Magnify,
Rotate. Some would create new sprites others would apply to existing sprite.
May have button on Save Box to make sprite name the same as that of the
sprite in the window. (This would only be sensical for original sprites).
Gather the sprites on a mode change - at present you can lose them.
// --------------------------------------------------------------------------